home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13309 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.eiffel,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng
  4. Subject: Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer
  5. Date: 24 Mar 1996 14:18:54 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4j4hoeINNfoi@keats.ugrad.cs.ubc.ca>
  8. References: <1995Jul3.034108.4193@rcmcon.com> <314DADD4.3DE@oc.com> <4j3ohvINN4vu@keats.ugrad.cs.ubc.ca> <31557321.6A8B@iadfw.net>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <31557321.6A8B@iadfw.net>, Larry Weiss  <lfw@iadfw.net> wrote:
  12.  >Kazimir Kylheku wrote:
  13.  > > 
  14.  > > The above are ones you wouldn't want to redefine anyway.  I doubt you could
  15.  > > make a better strcpy() or abs() than compiler-generated inline code!
  16.  > > --
  17.  >
  18.  >You may just want or need learn how many invocations of that logic occur.
  19.  
  20.  >Remember, I'm asking how does a hacker feel about the inability to depend on these
  21.  >calls actually executing an easily replaceable or patchable code segment.
  22.  >I suspect that a hacker would take your last sentence as a challenge, and
  23.  >then if he/she were good enough, well who knows?
  24.  >
  25.  >I do understand the software engineer's needs (although even in that domain I
  26.  >like to think that I can readily employ the memory leak-detector tools that rely on
  27.  >not inlined malloc() free() code generation).    Although while wearing my
  28.  
  29. You should be able to. I don't think that malloc and free are commonly inlined.
  30. Though if they are inlined in a library to which you don't have sources, you
  31. are a poor soul. Library creators should watch out for this. I think that a
  32. reasonable practice is to _not_ inline the functions when optimization is not
  33. turned on. GCC behaves this way, in addition to providing an explicit switch.
  34.  
  35. Conscientious developers build two versions of a library.  For example, the
  36. ncurses distribution will build a debugging version of the library as well as
  37. an optimized production version. Even if malloc() were a builtin, I could count
  38. on the GCC-compiled debugging library to actually use the call.
  39.  
  40.  >engineer's cap, if there were really good runtime efficiency gains to be had
  41.  >by inlining those calls .... well it would be a tough decision.  (and the problem
  42.  >there is with my 3rd party library code where the inline/not-inlined decisions
  43.  >are already imposed, either helping or restricting my leak-detector.
  44.  
  45. Having only one version, with all the inline business in place is a big bummer.
  46. Here is where the hacker as well as engineer in me would get pretty upset!
  47.  
  48. -- 
  49.  
  50.